IETF Logo Mail Archive

Re: [rtcweb] Meaning of SHOULD support/use interleaving

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Fri, 31 October 2014 18:17 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796171A03A6 for <rtcweb@ietfa.amsl.com>; Fri, 31 Oct 2014 11:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC4vddlBfERD for <rtcweb@ietfa.amsl.com>; Fri, 31 Oct 2014 11:17:57 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F035E1A03A3 for <rtcweb@ietf.org>; Fri, 31 Oct 2014 11:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3255; q=dns/txt; s=iport; t=1414779476; x=1415989076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GWEnnVFfoUIGCn9D8TbUdJvZGzE2lqu4Qln7s7AmadA=; b=LR//8KKv0qQxNOfRyS7hySI7MoRb8SJ80xFhpiLSGnNr8vgWiPzXXv9T f32eFhj6X6J4lpp3Yy6tz5H/yhU/p2Qz7JQTBaTZQ5eoPsIJ29KSI46il Ha2mAdYjzuDnwrI6jLN1qJxQaue1Gmbaogp6pqnZTqKsdaN0BvUnA2ir+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0FAP7QU1StJA2D/2dsb2JhbABcgw6BLATUdQKBGRYBAQEBAX2EAwEBBHkQAgEIRjIlAgQKBAUbiCbLJAEBAQEBAQEBAQEBAQEBAQEBAQEZkGUrB4RLBYszhEOCH4cQhFOBMZEOhAmDeGwBgUeBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="92209864"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 31 Oct 2014 18:17:56 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9VIHuad005191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 18:17:56 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 13:17:55 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving
Thread-Index: AQHP9Tb9flhRKPwK+0CahQGt2FaUYQ==
Date: Fri, 31 Oct 2014 18:17:55 +0000
Message-ID: <D0793BB3.3D80A%mzanaty@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <EA00639E-2008-4BD2-88F2-27AAEE9DA213@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <CD364160-0A33-4E74-B114-04BDA33E40D3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <CABcZeBOuiTk8Ont314aenemUVPxkiLk7jScpZ3DR-90TuzN4NQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> <D0757214.3D0B4%mzanaty@cisco.com> <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken.de> <D076BBBF.3D478%mzanaty@cisco.com> <9DFFB0BA-078A-44BC-BE78-E31077A2174C@lurchi.franken.de>
In-Reply-To: <9DFFB0BA-078A-44BC-BE78-E31077A2174C@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.81.3.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <78E2E79CA77DBA479BD467993A584B3F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p9BAgnfmCr9DUHLHFV46aGY9N94
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2014 18:17:59 -0000

Hi Michael,
Merging your points and replying here since we are firmly in rtcweb cases.
We can summarize for tsvwg once concluded (if we reach any conclusion).

Consider real rtcweb apps that have many potentially large blobs to
transfer, like proxy browsing, webtorrent, chats with file exchange, games
with object exchange, etc. Developers may think sending these blobs as
messages on an unordered channel would work without HOL blocking. But they
would be wrong since the current NDATA spec actually blocks, effectively
behaving like an ordered channel.

Once they debug this, they will rewrite the app to either:
1) create a new channel for every blob, which is excessive overhead for
the app, browser and SCTP stack (but NDATA does at least enable this
solution), or
2) fragment blobs in the app, which adds (some but less) overhead for the
app (and defeats NDATA).

These are the only ways to get unordered, non-blocking delivery. At least
NDATA makes the app hack 1) possible since channels don¹t block each
other. But it would be far more useful if unordered channels did not block
like ordered ones.

More inline.

Cheers,
Mo

On 10/30/14, 2:53 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
wrote:
Can you be a bit more specific? My understanding is:
1. Messages sent on one data channel should not block messages sent on a
different channel.
   I hope we agree on this and this goal can be reached with N-DATA.
2. If you send a larger message on an ordered data channel, it will block
other
   messages sent on the same data channel. Since it is an ordered channel,
this can't
   be avoided. I hope we also agree on this.
3. If you send a large message on an unordered data channel, and a small
one after
   that, there is no statement made in which these messages would be
delivered.
   Are you focussing on this and do you want to require some sort of
reordering?

Mo: Agreed on 1 and 2, with the admittedly minor caveat mentioned earlier
on 2 about blocking sender transmission vs. receiver delivery to app. For
3, which is indeed my focus, agreed the W3C spec makes no statement about
order (since the channel is unordered!), but the NDATA spec actually does
mandate HOL order for messages>MTU, which is counter to the whole point of
an unordered channel. A developer must override defaults to get an
unordered channel, presumably to get faster, non-blocking delivery for the
individual messages. Otherwise, what is the point of unordered channels if
they block just like ordered ones?


On 10/30/14, 5:55 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
wrote:
Assume an unordered data channel dc and the application calls
dc.send(big_msg);
dc.send(small_msg);
How do you decide whether the intended behaviour is either
(a) deliver big_msg before small_msg
(b) deliver small_msg before big_msg
I don't see any way in the W3C API to indicate this. Both alternative
might the appropriate in different scenarios.

Mo: The point of unordered channels is to send and receive everything
whenever it becomes available. The transport does not need to worry about
providing any specific ordering, but it is not expected to block based on
internal ordering rules.

v2.23.0 | Report a Bug | By Email